The goal of a field-programmable gate array (FPGA) to application-specific integrated circuit (ASIC) conversion is to replace an FPGA with a dropped in ASIC. This sounds simple enough. However, various issues can arise and make a simple migration complex, while causing a schedule shift. If these issues are dealt with early in the design phase, one can almost always be guaranteed on time delivery of 100 percent. As the price per part for an ASIC can be as low as 10 percent of an equivalent FPGA, this change allows the designer to save a significant amount of money-not always an easy process. Below we will attempt to describe a typical migration design flow while pointing out common pitfalls a designer may face and how these issues could be approached.

Typically, the migration database consists of a captured design, test fixtures, timing constraints, and target technology requirements. The captured design can be in variety of formats, including RTL, a gate level netlist, or schematics. The first step is to establish a baseline design in the target technology. This consists of translating the captured design to the target technology. If the design is captured in schematics or a gate-level netlist, the translation can be done manually or with the assistance of a netlist translator software package. If the design is captured in RTL, the baseline netlist is easily established by using a synthesis tool with the target technology libraries. In many cases, the design will contain some macrocells, most likely in the form of RAMs, ROMs, or phase-locked loops (PLLs).

The various macrocell types available from ASIC vendors generally supercede those available in FPGA technology. ASIC vendors have a wide array of PLLs to choose from, while RAMs and ROMs are easily generated from the vendors macrocell compiler. In the event a particular macrocell isn't available in the target technology, the designer has two options: include custom design of the required macrocell and incurring additional cost, or implementation of the macrocell's logic function in gates. For example, if a 2R/2W RAM isn't available in the target technology, it could be implemented as an array of registers so long as the timing, power, and area requirements are met.

After netlist translation

Once the netlist is completely translated, the test fixtures should be run on the netlist to verify correct functionality. If the design is completely synchronous, running the test fixtures on a cycle basis should prove the functionality of the design. In the case that the design isn't completely synchronous, it may be tricky to get the test fixtures to pass and artificial delays may have to be introduced to the netlist. Once the functional test fixtures have passed, the netlist can generally be considered base-lined. Keep in mind that many FPGA designs may not have a test bench to validate the design. In addition, many early applications used asynchronous internal design techniques. Either can result in major issues in establishing compatibility with the targeted ASIC.

One situation the functional simulations don't cover is programming the FPGA. Since the FPGA may be based on volatile memory, it would need to be programmed upon system startup. Depending upon the configuration of the FPGA in the system, there are several methods by which it can be programmed. The ASIC designer must take into consideration the system requirements of the ASIC during programming and be sure it doesn't conflict with ASIC compatibility. For example, the system may be designed such that it expects a time delay between system turn on based on a "Done" signal from the FPGA, signaling programming is complete. In this case, a counter could be used to delay the assertion of the "Done" signal.

The next step is to select the proper system I/O drivers. Usually the I/O standards supported by FPGAs are a subset of the I/O standards of ASICs. However, it may be difficult to find an I/O driver that is an exact match in propagation delay, transition delay, and drive strength. In this case the system designer should be consulted.

SPICE simulation of the ASIC I/Os can be done under varying voltage, temperature, and process conditions to ensure the selected I/O drivers meet the system requirements. In the event the I/O's in the ASIC vendors standard library don't meet the system requirements, custom I/Os can be developed. However, this can mean a significant increase in the nonrecurring engineering (NRE) cost.

How testable is the ASIC?

Before continuing through the design flow to the back end, testability of the ASIC should be discussed. Though silicon-manufacturing tests are a non-issue for FPGA designs, they are critical for an ASIC. Most commonly, the vendor will require a stuck-at-fault test (scan), a quiescent current test, as well as tests to validate the integrity of the macrocells and interconnects.

Ideally, functional tests would be used to satisfy the manufacturing test requirements but unfortunately the functional tests aren't usually sufficient, and in many cases they aren't even available.

Support for manufacturing tests requires inserting additional logic and possibly additional primary I/O.

For the scan test, there are several options to consider. First, if the functional tests are tester friendly, they can be used for Fault Grading. Any remaining undetected or untested faults can be added to the fault coverage list using a sequential automatic test program generation (ATPG) tool. Often, due to tester limitations, functional test fixtures can't be run on the tester. In this case, internal scan can be inserted, providing sufficient controllability and observability of the circuit to perform combinational ATPG to provide high fault coverage. Since the original design probably didn't include support of design for test (DFT), it's entirely possible modifications are required to make the design DFT compatible. Many different design situations can require a combination of test methods to achieve sufficient fault coverage. The key is to obtain the highest fault coverage possible with the smallest number of test vectors, the minimum testability logic overhead in the design, and in the quickest way possible.

Another testability issue worth discussing is JTAG. Although every FPGA can physically support JTAG, the target system may not use all of it. Since it could take considerable effort to design the ASIC JTAG to emulate the FPGA JTAG, it's worth consulting the system designer to determine what functionality is required of the JTAG logic.

The four P's

At this point it's probably a good idea to take a look at I/O pin placement and package planning. Several factors can play a role in migration regarding I/O pin placement and package selection. Since the ASIC needs to be a pin for pin compatible replacement, I/O placement seems as though it would be a non-issue, however this isn't always the case. In terms of package planning, the location of power and ground pins on a FPGA part is fixed. In most package types, this isn't a concern. In array ASIC packages the locations for power and ground are fixed. In a one-to-one mapping situation however, a signal location on the FPGA may lie on a power or ground location on the ASIC and this can cause a big problem. There are two possible solutions: a custom substrate can be designed, or the system board can be re-designed. This involves a cost/time trade-off the designer must evaluate. Often, the cost and turn-around time advantages of a custom substrate outweighs a board re-design.

Other issues that can impact pin-for-pin location compatibility are the addition of signals for testability and simultaneous switching outputs (SSOs). As a minimum for scan logic, one pin will need to be added-assuming the part is put into a scan friendly state through the test access part (TAP) controller and the scan I/O signals are shared with functional I/O. Several pins may have to be added to accommodate macrocell testability, depending upon the implementation of the test logic. A location requirement for the P/G pins means a fixed location requirement for the P/G pads on the die.

If the SSO requirements are not met with this configuration, additional P/G pads will have to be added.

An FPGA to ASIC migration can easily be mistaken as a simple, no problem process, but each conversion is unique. At each stage of the design flow, we have pointed out at least one problem and possible solutions. Although it would be impossible to list every possible problem and solution, we hope the problems discussed here are general enough to apply to most conversions.